Small addition to PR #7439.

The goal of broadcastWatches is to notify cache watchers of any new data
resulting from cache writes.

However, it's possible for cache writes to invalidate watched queries in a
way that does not result in any differences in the resulting data, so this
watch.lastDiff caching saves us from triggering a redundant broadcast of
exactly the same data again.

Note: thanks to #7439, when two result objects are deeply equal to each
another, they will automatically also be === to each other, which is what
allows us to get away with the !== check in this code.

Revisiting PR #6891, which was reverted by commit c2ef68f.

With the introduction of canonical cache results (#7439), the strict
equality check in setDiff is about to become mostly synonymous with deep
equality checking (but much faster to check), so we need to deal with the
consequences of #6891 one way or another.

As evidence that this change now (after #7439) has no observable impact,
notice that we were able to switch back to using !equal(a, b) without
needing to fix/update any failing tests, compared to the few tests that
needed updating in #6891.

However, by switching to deep equality checking, we allow ourselves the
option to experiment with disabling (or periodically clearing) the
ObjectCanon, which would presumably lead to broadcasting more !== but
deeply equal results to cache.watch watchers.

With deep equality checking in setDiff, those !== results will get past
the filter in the same cases canonical objects would, so there's less of a
discrepancy in client behavior with/without canonization enabled.

Although cache result canonization (#7439) is algorithmically efficient
(linear time for tree-shaped results), it does have a computational cost
for large result trees, so you might want to disable canonization for
exceptionally big queries, if you decide the future performance benefits
of result canonization are not worth the initial cost.

Fortunately, this implementation allows non-canonical results to be
exchaged later for canonical results without recomputing the underlying
results, but merely by canonizing the previous results.

Of course, this reuse happens only when the cache has not been modified
in the meantime (the usual result caching/invalidation story, nothing
new), in which case the StoreReader does its best to reuse as many
subtrees as it can, if it can't reuse the entire result tree.

Although cache result canonization (#7439) is algorithmically efficient
(linear time for tree-shaped results), it does have a computational cost
for large result trees, so you might want to disable canonization for
exceptionally big queries, if you decide the future performance benefits
of result canonization are not worth the initial cost.

Fortunately, this implementation allows non-canonical results to be
exchaged later for canonical results without recomputing the underlying
results, but merely by canonizing the previous results.

Of course, this reuse happens only when the cache has not been modified
in the meantime (the usual result caching/invalidation story, nothing
new), in which case the StoreReader does its best to reuse as many
subtrees as it can, if it can't reuse the entire result tree.

Revisiting PR #6891, which was reverted by commit c2ef68f.

With the introduction of canonical cache results (#7439), the strict
equality check in setDiff is about to become mostly synonymous with deep
equality checking (but much faster to check), so we need to deal with the
consequences of #6891 one way or another.

As evidence that this change now (after #7439) has no observable impact,
notice that we were able to switch back to using !equal(a, b) without
needing to fix/update any failing tests, compared to the few tests that
needed updating in #6891.

However, by switching to deep equality checking, we allow ourselves the
option to experiment with disabling (or periodically clearing) the
ObjectCanon, which would presumably lead to broadcasting more !== but
deeply equal results to cache.watch watchers.

With deep equality checking in setDiff, those !== results will get past
the filter in the same cases canonical objects would, so there's less of a
discrepancy in client behavior with/without canonization enabled.

This reimplementation of the stable `stringify` function used by
`getStoreKeyName` builds on the `ObjectCanon` introduced by my PR #7439,
which guarantees canonical objects keys are always in sorted order.